home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 90 < prev    next >
Text File  |  1994-08-27  |  3KB  |  70 lines
  1. Subject: Re: Proposal
  2. Date: Wed, 1 Jun 1994 09:35:07 +0200 (MDT)
  3. In-Reply-To: <H.ekK.D9IxnaYtw3o@elfhaven.ersys.edmonton.ab.ca> from "Michel Forget" at May 22, 94 01:33:14 am
  4. From: Annius.Groenink@cwi.nl (Annius Groenink)
  5. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  6.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  7.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  8. Mime-Version: 1.0
  9. Precedence: bulk
  10.  
  11.  
  12. > [> CTRL F -                 Find
  13. > [> CTRL G -                 Find next
  14. > [> CTRL R -                 Replace *1
  15. > [> CTRL T -                 Replace Next
  16. > 
  17. > What about "Find Previous" or "Replace Previous"?  In MasterBrowse,
  18. > I use ^E for "Find Previous" mainly because EFG = Previous/Find/Next
  19. > so it is easy to remember.
  20.  
  21. It is fairly standard to use Shift CTRL G for find previous (shift being
  22. the modifier of ^G).  Could do the same with ^T.  (And even with ^F and ^R
  23. which would reverse the direction before opening the dialog).
  24.  
  25. > [> CTRL B -                 Bold for word processors
  26. > [> CTRL I -                 Show Info /Italic for word processors
  27. > [> CTRL U -                 Underline in text editors
  28. > 
  29. > How about ^L for "light" text in word processors.
  30.  
  31. Maybe we should have separate chapters for a number of typical application
  32. paradigms such as:  an editor,  a word processor (quite different),
  33. a drawing package (things on the num pad for scaling) etc.  The above three
  34. definitely do not belong in a general standard.
  35.  
  36. > [> CTRL [ -                 Block start
  37. > [> CTRL ] -                 Block end
  38.  
  39. This won't work on a German keyboard.  What about function keys for this
  40. purpose?  We haven't considered those yet.  But perhaps we should save
  41. the function keys for whatever we cannot sensibly assign letters to...
  42.  
  43.  
  44. > This is good as far as it goes, but I think it needs more work.  Such
  45. > as, what gadgets should a windowed dialog box have?  (I personally
  46. > use the MOVER|CLOSER set.)  Also, it would be nice if we decided which
  47.  
  48. Smaller is OK.  Is it?  Perhaps not if a dialog is modal?
  49.  
  50. > keypresses should be used.  For example, EGEM has a very full set of
  51. > dialog commands that allows access to the clipboard, a history buffer,
  52. > moving to the first editable field, the last editable field, etc.
  53. > We should standardize this (if we can) while we are doing the ohter
  54. > keyboard shortcuts.
  55.  
  56. ^V should definitely work.  Also, the right mouse button should be paste
  57. in dialog fields like it is (well, the middle button is) on UNIX.
  58.  
  59.  
  60. > [> *1 There's a good arguement for using CTRL F,G,H for Find, Find
  61. > [>    Next and Replace.
  62. > 
  63. > Not really....  :)
  64.  
  65. On the contrary,  there is not really a good argument for having ^R and ^T
  66. as that obsolete search and replace paradigm is dangerous.  A well
  67. implemented REPLACE operation that swaps selection and cut/paste block on
  68. a fragment-fragment basis is a much better option as it is reversible.
  69.  
  70.